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1.0  BACKGROUND/APPROACH 

This  report  documents  work  performed  by  Meridian  Corporation  under  contract 
No.  MDA903-83-C-0342.  Volume  II  of  this  report  concerns  the  efforts  undertaken 
with  respect  to  a  Milestone  Tracking  System.  The  purpose  of  this  task  was  to 
analyse  the  feasibility  and  cost  effectiveness  of  developing  a  milestone  tracking 
system  for  internal  use  within  DARPA  which  was  capable  of  utilising  existing 
DARPA  data  bases.  As  defined  in  this  document,  milestones  Include  a  wide 
range  of  Internal  and  external  developments  as  well  as  decision  points  which 
may  be  of  interest  to  DARPA  managers.  Specifically,  these  Include: 


<&  Technical  achievements; 

jP  Technical  decision  points; 

jf  Financial  decision  points^ 

tP  Points  of  inter-project  dependencies;  and 

Jp  External  events/considerations . 

c^The  purposes  initially  identified  for  a  milestone  tracking  system  were 
threefold.  First,  the  system  was  envisioned  to  be  a  mechanism  to  provide 
program  managers  with  a  concise  representation  of  their  program  activities. 

Such  activities  might  Include  Internal  reviews,  project  accompli shmenj^;  finan¬ 
cial  mlleatones,  program  interfaces,  and  evsnts  of  public  interest.  Second, 


the  system  «ps  conceived  to  provide  an  automatic  prompting  of  milestones  and/or 
critical  events  identified  by  the  user.  Third,  the  system  was  viewed  as  a 
mechanism  to  retain  an  historical  data  bass  on  the  conduct  of  DARPA  programs. 


However,  upon  closer  examination  of  user  requirements 


soon  became  evident 

that  the  system  also  had  utility  in  providing  input  to  reprogramming  decisions 
through  the  analysis  of  imbedded  dependency  networks.  The  potentlsl  for  this 
application  is  analysed  in  Section  2.0.  / 

At  the  outset,  the  milestone  tracking  system  was  conceived  as  a  centralised 


HIS  application,  similar  in  nature  to  the  system  designed  to  address  forward 


funding.  Potential  uaers  were  identified  and  queried  concerning  their  personal 
requirements  for  a  milestone  tracking  system.  Representatives  were  Interviewed 
from  each  potential  user  group  within  DARPA,  Including  the  PMO  Director's  Office, 
the  Program  Management  Office,  Technical  Offices,  Financial  Management  Division 
of  PMO,  and  MISD. 

Baaed  upon  the  interviews  conducted  with  these  diverse  individuals,  several 
common  concerns  were  raised.  Foremost  among  these  concerns  was  the  perception 
that  exiting  milestone  tracking  systems  (maintained  on  hard  copy  mostly)  were 
adequate  for  most  users.  This  viewpoint  was  almost  universally  held,  with  a 
notable  exception  being  the  PMO  Director's  Office.  In  addition,  it  was  widely 
believed  that  the  requirements  for  data  entry  would  be  overwhelming  to  a  staff 
which  was  already  fully  utilised.  This  problem  was  particularly  noted  in  places 
irtiere  the  availability  of  support  staff  was  limited.  Further,  because  of  the 
classified  nature  of  many  program  milestones,  the  security  of  access  to  the 
data  was  perceived  to  be  a  formidable  obstacle  to  the  successful  implementation 
of  a  centralised  system.  Finally,  a  few  potential  users  expressed  reservations 
concerning  their  ability  to  monitor  the  integrity  of  the  data  once  it  was  input 
to  the  data  base,  and  some  feared  that  unauthorised  access  to  information  about 
their  programs  may  prove  to  be  detrimental. 

Because  of  these  four  reasons,  a  centralised  MIS  application  did  not  appear 
to  be  warranted.  However,  considerable  interest  was  expressed  in  an  interactive 
microcomputer  application.  Such  an  application  would  have  utility  primarily 
within  MO,  principally  for  the  Director's  Office  but  also  for  Program  Management 
Officers.  The  system,  as  in  the  case  of  the  Forward  Funding  Tracking  System, 
was  necessarily  constrained  to  rely  on  existing  data  sources,  while  accenting 
the  benefits  obtainable  from  automated  analysis  and  interpretation.  In  addition, 
a  principal  opportunity  that  the  system  might  realise  was  in  the  maintenance  of 
historical  records  of  planned  versus  actual  performance  so  that  the  memory  of  a 


program's  progress  might  be  sustained  through  personnel  changes,  baseline  changes, 
and  funding  redirection. 

Several  potential  user  requirements  were  identified  for  an  Interactive 
microcomputer  application.  Foremost  among  these  requirements  was  the  need  for 
the  system  to  be  sufficiently  Interactive  that  it  may  be  considered  ’‘user- 
friendly"  by  professionals  who  are  not  computer-oriented.  Second,  the  system 
needed  to  be  sufficiently  flexible  to  permit  the  user  to  tailor  meaningful 
outputs  to  respond  to  a  variety  of  special  situations.  Third,  a  aeries  of 
needs  urns  identified  relating  to  the  system's  ability  to  sort  milestones  by 
a  wide  range  of  parameters,  Including  the  importance  of  the  milestone  (as 
judged  by  the  user),  the  time  horizon  in  which  the  milestone  occurs,  the 
Technical  Office  sponsoring  the  program,  and  the  financial  implications  of  the 
achievement  of  (or  the  deviation  from)  the  milestone.  This  last  capability 
Implies  the  construction  of  a  dependency  network  to  some  level  of  detail,  which 
in  turn  may  indicate  a  fruitful  area  for  Interface  with  the  Forward  Funding 
Tracking  System  described  in  Voluae  I.  Finally,  as  noted  earlier,  the  last 
functional  requirement  placed  on  the  system  was  the  need  to  maintain  an 
historical  record  of  milestones  as  they  are  scheduled,  as  they  are  achieved, 
and,  in  the  event  of  sllppagges,  the  reasons  why  deviations  from  schedule 
occurred. 

In  response  to  these  four  requirsacnts.  Meridian  has  constructed  prototype 
output  report  which  address  the  identified  milestone  tracking  needs.  These 
output  reports  and  preliminary  indications  of  how  they  may  be  utilized  are 
described  in  Section  2.0. 


2.0  REQUIREMENT 

In  order  to  effectively  maintain  programmatic  control  over  DARPA  research 
efforts,  the  Director  of  the  Program  Management  Office  (PMO)  must  have  access 
to  schedule  and  performance  data  for  all  projects.  These  data  currently  exist 
in  a  totally  manual  form  —  periodic  project  status  briefing  reports  are  sent 
in  to  the  Director's  Office  where  they  can  be  referenced  visually.  An  automated 
method  of  storing  and  accessing  this  data  would  allow  the  Director  to  stay 
abreast  of  the  status  of  ongoing  projects  more  efficiently,  to  anticipate 
problem  areas,  and  to  identify  potential  program/schedule/budget  Impacts.  This 
section  describes  the  specific  parameters  of  such  an  automated  project  schedule 
support  system. 

2.1  Data  Entry 

Data  for  automated  milestone  tracking  will  come  primarily  from  the  progress 
status  briefing  reports  sent  to  the  Director,  PMO.  The  data  elements  will  be 
keyed  Interactively  into  an  IBM  Personal  Computer  by  a  data  entry  clerk.  The 
Director  or  a  designated  analyst  will  need  to  be  Involved  with  determining  and 
entering  certain  data  elements  (specifically  dependency  information  and  priority 
designations).  Data  will  consist  of  two  specific  types  —  header  (identifying) 
information  for  each  project  and  characteristic  data  concerning  each  milestone. 
Project  header  information  will  consist  of: 
o  Project  title 
o  Contractor  name(s) 
o  Technical  Office  assigned  to 

o  Identification  code  (unique  for  each  project,  could  include  Technical 
Office  designation  and  possibly  type  of  project  code) 

Milestone-specific  information  will  consist  of: 

o  Milestone  title  (descriptive) 
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o  Milestone  identifier  —  unique  code  also  designating  the  type  of 

milestone  (such  as  start  date,  completion  date,  program  review,  etc.) 

o  Priority  designation  —  the  Director  will  have  the  ability  to  identify 
those  milestones  which  should  be  assigned  particular  importance 

o  Schedule  Date(s)  —  the  quarter(s)  in  which  the  milestone  is  expected 
to  be  achieved  (this  will  be  a  multiple  field  to  accommodate  schedule 
revisions,  each  of  which  must  be  stored  and  retrievable) 

o  Actual  completion  date 

o  Preceding  dependencies  -  list  of  the  milestone  identifiers  which  must  be 
completed  before  the  activity  which  cumlinates  in  this  milestone  begins 

o  Succeeding  dependencies  —  list  of  the  milestone  identifiers,  the 
subsequent  activities  which  cannot  begin  prior  to  the  completion  of 
this  milestone. 

There  are  two  particularly  salient  points  concerning  data  elements  which 
must  be  discussed,  namely: 

1)  Milestones  must  be  limited  to  those  events  which  are  measurable  and 
achievable,  such  as  “Begin  Contract"  or  "Conduct  Preliminary  Program 
Bavlev" .  Decision  points  should  be  included  as  milestones  where 
appropriate. 

2)  Care  must  be  taken  in  determining  milestone  dependencies.  For  the 
sake  of  processing  simplicity,  dependencies  should  be  limited  to 
those  relationships  between  the  completion  of  one  milestone  and  the 
commencement  of  the  activity  leading  to  the  dependent  milestone. 

It  is  therefore  necessary  to  determine  and  enter  a  milestone  which 
corresponds  to  the  beginning  of  the  dependent  activity. 


2.2  Baport  Generation 

The  basic  output  format  for  this  system  will  be  a  graphic  representation 
along  a  time  line  of  the  schedule  status  of  a  project  or  projects.  Output 
reports  must  also  be  able  to  be  tailored  to  satisfy  a  particular  report  re¬ 
quirement.  The  specific  report  generation  options  which  must  be  available 

are: 


o  Selection  —  inclusion  of  only  those  projects,  milestones  and/or  data 
items  which  satisfy  user  defined  parameters,  such  as: 


-  Only  those  projects  in  a  particular  office 

-  Only  those  projects  of  a  particular  type 


-  Only  those  milestones  which  occur  after  the  first  quarter  of  a  given 
fiscal  year 

-  Only  those  milestones  of  a  particular  type 

-  Only  the  latest  scheduled  date  for  a  milestone 

o  Sorting  —  grouping  of  project  milestone  charts  in  a  fashion  designated  by 
the  user,  such  as  by  Technical  Office,  project  type,  or  completion 
milestone  by  time 

o  Summarisation  —  compressing  the  multiple  project  milestones  into  a 
single  line  representation,  perhaps  a  bar  with  some  user-selected 
milestone  symbols  added 

o  Dependency  analysis  —  the  ability  to  display  in  a  condensed  manner, 
those  milestones  which  have  defined  interrelationship 

o  Option  combinations  —  the  ability  to  mix  and  match  report  generation 
options  discussed  above  into  any  combination. 

Figure  2-1  through  2-6  provide  rough  examples  of  the  ki  reports 

which  should  be  available  from  the  milestone  tracking  system.  Special  features 

of  each  are  noted  where  appropriate. 


b — Superscript  niabera  Indicate  schedule  revision  versions 


a — User  selected  option  to  display  only  those  which  he/she  had  previously  designated  as  priority 
b — Flled-ln  diamond  indicates  completed  milestone 
c — Superscript  numbers  indicate  schedule  revision  versions 


3.0  CONCLUSIONS  AND  RECOMMENDATIONS 


The  narrow  range  of  Interest  expressed  in  developing  an  automated  milestone 
tracking  system  has  led  the  study  team  to  the  conclusion  that  a  single-user, 
microcomputer-based  system  is  the  optimal  system  alternative.  The  system 
design  and  development  analyses  to  be  conducted  in  Phase  II  should  therefore 
address  the  procedures  and  specific  requirements  of  developing  and  Implementing 
a  microcomputer-based  solution.  To  that  end,  the  tasks  which  we  recommend 
pursuing  In  Phase  II  consist  of: 

o  Developing  a  system  design  specification  for  a  microcomputer-based 
system.  Particular  emphasis  should  be  paid  to  determining  the  degrees 
of  user-friendliness  and  user  flexibility  required 

o  Preparing  an  implementation  plan  for  system  development,  implementation, 
and  maintenance.  Specific  topics  to  be  addressed  include  costs, 
schedules,  training  requirements,  procedural  Impacts,  and  data  re¬ 
quirements 

o  If  funding  permits,  Initiating  software  development.  The  more  narrow 
(as  opposed  to  a  centralised  application)  scope  of  the  recommended 
solution  will  foreshorten  the  "Solution  Space"  analysis  resource 
requirements.  At  the  discretion  of  the  COIR,  the  implementation  of 
the  milestone  tracking  system  can  be  accelerated  by  using  the  remaining 
funds  to  initiate  software  development. 

In  addition,  owing  to  Interrelationships  between  milestone  tracking  and 
other  management  functions  undertaken  at  PMO,  Meridian  recommends  that  the 
Phase  II  efforts  also  Include: 

o  The  expansion  of  the  scope  of  the  system  to  Include  a  lower  level  of 
program  milestones 

o  The  definition  of  mechanisms  which  will  identify,  on  a  continuing  basis, 
the  financial  istpllcatlons  of  program  milestones 

o  The  Identification  of  commonalities  between  milestone  tracking  and  the 
management  of  DARPA  resources. 
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